fix(ducklake): GC leaked inline tables to stop multi-GB RSS growth - #767

Root cause

DuckLake leaks ducklake_inlined_data_* physical tables — upstream bug duckdb/ducklake#1065:

• DuckLake creates a ducklake_inlined_data_<table_id>_<schema_version> table per schema version.
• schema_version bumps on every DDL — including the SET PARTITIONED BY / SET SORTED BY we issue for each hep_proto_* and otlp_* table on every startup.
• No maintenance path ever DROPs those tables: flush_inlined_data only DELETEs their rows, expire_snapshots only removes registry rows, cleanup_old_files ignores them.

They accumulate forever, and the DuckLake extension rebuilds an in-memory stats map (DuckLakeCatalog::ConstructStatsMap) over all of them on every catalog refresh → RSS climbs without bound even with a tiny catalog and few Parquet files.

This is the same defect diagnosed and fixed in the sibling ingest service (heap profile pinned ~2.5 GB to ConstructStatsMap fed by ~870 leaked inline tables; dropping the empty ones took RSS from 4.1 GB back to ~300 MB).

Fix

• Startup GC (GCOrphanInlineTables). Before ATTACH — while the sqlite catalog is still exclusively ours, the same window EnableSQLiteWALMode already uses — drop every empty ducklake_inlined_data_* table and delete its ducklake_inlined_data_tables registry row. Empty ⇒ rows already flushed to Parquet, so the cleanup is lossless. Best-effort, non-fatal. Non-empty inline tables (un-flushed legacy rows) are left untouched.
• Stop the churn. SET PARTITIONED BY / SET SORTED BY now run only when the table is first created (gated on information_schema.tables), for both HEP (tables.go) and OTLP (otlp_storage.go) tables — not on every boot. Re-issuing them bumped schema_version each restart and spawned a fresh leaked inline table per table per restart.

Bump 11.0.234 → 11.0.235.

Notes

• sqlite catalog only (the GC SQL is sqlite); homer's DuckLake catalog is always sqlite.
• Existing nodes drain their backlog at the next restart (GC runs at startup, drops only empty tables). To reclaim immediately: stop the service, back up the catalog .sqlite, DROP the empty ducklake_inlined_data_* tables + their registry rows, VACUUM, restart.

Test plan

• Start against a catalog with a ducklake_inlined_data_* backlog; confirm the "DuckLake inline GC: dropped N ..." log and that ducklake_inlined_data_tables shrinks to the non-empty set.
• Restart a few times; confirm the inline-table count stays flat (no churn) and existing tables keep their partitioning/sort order.
• Fresh catalog: confirm hep_proto_* and otlp_* tables are still created PARTITIONED BY (date) / SORTED BY (timestamp ASC).